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Abstract. Security policies are naturally dynamic. Reflecting this, there has been 
a growing interest in studying information-flow properties which change during 
program execution, including concepts such as declassification, revocation, and 
role-change. 

A static verification of a dynamic information flow policy, from a semantic per¬ 
spective, should only need to concern itself with two things: 1) the dependencies 
between data in a program, and 2) whether those dependencies are consistent 
with the intended flow policies as they change over time. In this paper we provide 
a formal ground for this intuition. We present a straightforward extension to the 
principal flow-sensitive type system introduced by Hunt and Sands (POPL ’06, 
ESOP ’ 11) to infer both end-to-end dependencies and dependencies at intermedi¬ 
ate points in a program. This allows typings to be applied to verification of both 
static and dynamic policies. Our extension preserves the principal type system’s 
distinguishing feature, that type inference is independent of the policy to be en¬ 
forced: a single, generic dependency analysis (typing) can be used to verify many 
different dynamic policies of a given program, thus achieving a clean separation 
between (1) and (2). 

We also make contributions to the foundations of dynamic information flow. Ar¬ 
guably, the most compelling semantic definitions for dynamic security conditions 
in the literature are phrased in the so-called knowledge-based style. We contribute 
a new definition of knowledge-based termination insensitive security for dynamic 
policies. We show that the new definition avoids anomalies of previous definitions 
and enjoys a simple and useful characterisation as a two-run style property. 


1 Introduction 

n 

Information flow policies are security policies which aim to provide end-to-end 
security guarantees of the form “information must not flow from this source to this des¬ 
tination”. Early work on information flow concentrated on static, multi-level policies, 
organising the various data sources and sinks of a system into a fixed hierarchy. The 
policy determined by such a hierarchy (a partial order) is simply that information must 
not flow from a to 6 unless a U fi. 

1.1 Dynamic policies 

Since the pioneering work of Denning and Denning IIDD77I . a wide variety of infor¬ 
mation-flow policies and corresponding enforcment mechanisms have been proposed. 
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// 

X ^ a; 

out 

X on a 

// 

X 74 a; 

out 

2 on a 


Fig.l 


Much recent work on information-flow properties goes beyond the static, multi-level 
security policies of earlier work, considering instead more sophisticated, dynamic forms 
of policy which permit different flows at different points during the excecution of a 
program. Indeed, this shift of focus better reflects real-world requirements for security 
policies which are naturally dynamic. 

For example, consider a request for sensitive employee infor¬ 
mation made to an employer by a regulatory authority. In order 
to satisfy this request it may be necessary to temporarily allow 
the sensitive information to flow to a specific user in the Human 
Resources department. In simplified form, the essence of this ex¬ 
ample is captured in Figure[T] 

Here x contains the sensitive information, channel a represents the HR user, and the 
policy is expressed by the annotations x ^ a(x may flow to a) and x -/y a (x must not 
flow to a). It is intuitively clear that this program complies with the policy. 

Consider two slightly more subtle examples, in each of which revocation of a per¬ 
mitted flow depends on run-time data; 

In program A, the revocation of 
X —> a is controlled by the value of 
y, whereas in program B it is con¬ 
trolled by the value of x itself. Note 
that the policy for A explicitly al¬ 
lows y —a so the conditional out¬ 
put (which reveals information about 
y) appears to be permissible. In pro¬ 
gram B the conditional output re¬ 
veals information about x itself, but 
this happens before the revocation. So should program B be regarded as compliant? 
We argue that it should not, as follows. Consider “the third output” of program B as 
observed on channel a. Depending on the initial value of x, the observed value may be 
either 2 (line 8 ) or 3 (line 9). Thus this observation reveals information about x and, in 
the cases where revocation occurs, the observation happens after the revocation. 

Unsurprisingly, increasing the sophistication of policies also increases the challenge 
of formulating good semantic definitions, which is to say, definitions which both match 
our intuitions about what the policies mean and can form the basis of formal reasoning 
about correctness. 

At first sight it might seem that increasing semantic sophistication should also re¬ 
quire increasingly intricate enforcement mechanisms. However, all such mechanisms 
must somehow solve the same two distinct problems: 

1. Determine what data dependencies exist between the various data sources and sinks 
manipulated by the program. 

2. Determine whether those dependencies are consistent with the flows permitted by 
the policy. 


- 

/*Program A*/ 

/*Program B*/ 

2 

// X, y —>■ a; 

// X ^ a; 

3 

out X on a; 

out X on a; 

4 

if (Y > 0) { 

if (x > 0) { 

5 

out 1 on a; 

out 1 on a; 

6 

// X 74 a; 

\ 

// X 74 a; 

} 

out 2 on a; 

8 

; 

out 2 on a; 

9 

out 3 on a; 

out 3 on a; 


Ideally, the first of these problems would be solved independently of the second, since 
dependencies are a property of the code, not the policy. This would allow reuse at two 
levels: a) reuse of the same dependency analysis mechanisms and proof techniques for 


different types of policy; b) reuse of the dependency properties for a given program 
across verification of multiple alternative policies (whether of the same type or not). 

In practice, enforcement mechanisms are typically not presented in a way which 
cleanly separates the two concerns. Not only does this hamper the reuse of analysis 
mechanisms and proof techniques, it also makes it harder to identify the essential dif¬ 
ferences between different approaches. 

Central Contribution We take a well-understood dependency type system for a sim¬ 
ple while-language, originally designed to support enforcement of static policies, and 
extend it in a straightforward way to a language with output channels (§|5]l. We demon¬ 
strate the advantages of a clean separation between dependency analysis and policy 
enforcement, by establishing a generic soundness result (§|6]) for the type system which 
characterises the meaning of types as dependency properties. We then show how the 
dependency information derived by the type system can be used to verify compliance 
with dynamic policies. Note that this means that the core analysis for enforcement can 
be done even before the policy is known: we dub this very static enforcement. More 
significantly, it opens the way to reuse of dependency analyses across verification of 
multiple types of information flow policy (for example, it might be possible to use the 
dependency analyses performed by advanced slicing tools such as Joanna and Indus). 

Foundations of Dynamic Flow Policies Although it was not our original aim and 
focus, we also make some contributions of a more foundational nature, and our paper 
opens with these (^|2]-Sj4ll. The semantic definition of security which we use is based on 
work of Askarov and Chong IIAC12I . and we begin with their abstract formulation of 
dynamic policies (ij2]l. In defining security for dynamic policies, they made a convincing 
case for using a family of attackers of various strengths, following an observation that 
the intuitively strongest attacker (who never forgets anything that has been observed) 
actually places weaker security demands on the system than we would want. On the 
other hand they observe that the family of all attackers contains pathological attacker 
behaviours which one certainly does not wish to consider. Due to this they do not give a 
characterisation of the set of all reasonable attackers against which one should protect. 
We make the following two foundational contributions: 

Foundational Contribution 1 We focus (i l3.3l l on the pragmatic case of progress in¬ 
sensitive security (where slow information leakage is allowed through observation of 
computational progress IIAHSS08II ). We argue for a new definition of progress insensi¬ 
tive security (PeffTTli. which unconditionally grants all attackers knowledge of compu¬ 
tational progress. With this modification to the definition from 0AC12L the problematic 
examples of pathological attackers are eliminated, and we have a more complete defini¬ 
tion of security. Consequently, we are able to prove security in the central contribution 
of the paper/or all attackers. 

Foundational Contribution 2 The definitions of security are based on characterising 
attacker knowledge and how it changes over time relative to the changing policy. As 
argued previously e.g., IIBS09I . this style of definition forms a much more intuitive basis 
for a semantics of dynamic policies than using two-run characterisations. However, two- 
run formulations have the advantage of being easier to use in proofs. We show (!j4|i that 
our new knowledge-based progress-insensitive security definition enjoys a simple two- 










run characterisation. We make good use of this in our proof of correctness of our central 
contribution. 

2 The Dynamic Policy Model 

In this section we dehne an abstract model of computation and a model of dynamic 
policies which maps computation histories to equivalence relations on stores. 

2.1 Computation and Observation Model 

Computation Model The computation model is given by a labelled transition system 
over configurations. We write (c, a)j^{c', o') means that conhguration (c, a) evalu¬ 
ates in one step to conhguration (c', a') with label a. Here c is a command and a € S 
is a store. In examples and when we instantiate this model the store will be a mapping 
from program variables to values. 

The label a records any output that happens during that step, and we have a distin¬ 
guished label value e to denote a silent step which produces no output. Every non-silent 
label a has an associated channel channel(a) G Chan and a value value(a). Channels 
are ranged over by a and values by v. We abbreviate a sequence of evaluation steps 

(co,Cro)^i^(ci,tTi)_^- ^{Cn,an) 

as (co,cro)->’"(cn,cr„). We write (cq, cro)->*(c', cr') if (cq, cro)_^»(c', tr') for some 
n > 0. We write the projection of a single step to some channel a 

as {c,a)-^a{c',a') where j3 = v if channel(a) = a and value(a) = v, and /3 = e 
otherwise, that is, when a is silent or an output on a channel different from a. 

We abbreviate a sequence of evaluation steps 

(co, 

as (co, cro)^->o (crt, cr„) where t is the trace of values produced on channel a with every 
silent e hltered out. We write (cq, (To)^->•a(c^ o"') if (cq, (c^ o"') for some n > 0. 

We use \t\ to denote the length of trace t and ti ^ t 2 to denote that trace ti is a 
prefix of trace t 2 . 

Attacker’s Observation Model We follow the standard assumption that the command 
c is known to the attacker. We assume a passive attacker which aims to extract informa¬ 
tion about an input store a by observing outputs. As in IIAC12I . the attacker is able only 
to observe a single channel. A generalisation to multi-channel attackers (which would 
also allow colluding attackers to be modelled) is left for future work. 

2.2 Dynamic Policies 

A flow policy specihes a limit on how much information an attacker may learn. A very 
general way to specify such a limit is as an equivalence relation on input stores. 

Example 1. Consider a store with variables x and y. A simple policy might state that 
the attacker should only be able to learn the value of x. It follows that all stores which 
agree on the value of x should look the same to the attacker. This is expressed as the 
equivalence relation u = p iff cr(x) = p(x). 

A more complicated policy might allow the attacker to learn the value of some 
arbitrary expression e on the initial store, e.g. x = y. This is expressed as the equivalence 
relation cr = p iff a{e) = p(e). 










Definition 1 (Policy). A policy P maps each channel to an equivalence relation = on 
stores. We write Pa for the equivalence relation that P defines for channel a. 

As defined, policies are static. A dynamic policy changes while the program is run¬ 
ning and may dictate a different P for each point in the execution. Here we assume that 
the policy changes synchronously with the execution of the program. That is, the active 
policy can be deterministically derived from the execution history so far. 

Definition 2 (Execution History). An execution history % of length n is a transition 
sequence (cq, cro)-^(ci, -^(c„,ct„). 

Definition 3 (Dynamic Policy). A dynamic policy D maps every execution history T-i 
to a policy D{'H). We write Da{'H)for the equivalence relation that is defined by D{'H) 
for channel a, that is to say, Da{T~i) = Pa where P = D{TP). 

Most synchronous dynamic policy languages in the literature determine the current 
policy based solely on the store in the final configuration of the execution history 
0AC12IBvDS13l . Definition [3 allows in principle for more flexible notions of dynamic 
policies, as they can incorporate the full execution history to determine the policy at 
each stage of an execution (similar to the notion of conditional noninterference used by 
||GM84|Zhal2| ). However, our enforcement does assume that the dynamic policy can be 
statically approximated per program point, which arguably is only feasible for policies 
in the style of 0AC12IBvDS13l . Such approximations can typically be improved by 
allowing the program to branch on policy-related queries. 

Since programs are deterministic, an execution history of length n is uniquely de¬ 
termined by its initial configuration (cq, CTo). We use this fact to simplify our definitions 
and proofs; 

Definition 4 (Execution Point). An execution point is a triple (cq, (Jq, n) identifying 
the point in execution reached after n evaluation steps starting from configuration 
(co,cro)- Such an execution point is considered well-defined iff there exists (c„,(T„) 
such that {co,ao)—^n(^Cn,crn). 

Lemma 1. Each well-defined execution point (cq, ctq, n) uniquely determines an exe¬ 
cution history 'H{co, ao, n) of length n starting in configuration (co, cro). 

In the rest of the paper we rely on this fact to justify a convenient abuse of notation, 
writing D{co, (Tq, n) to mean D{'H{cQ,<7Q,n)). 

3 Knowledge-Based Security Conditions 

Recent works on dynamic policies, including 0AC12IBDLG11IBNR08IBS10I . make 
use of so-called knowledge-based security definitions, building on the notion of gradual 
release introduced in IIAS07I . This form of definition seems well-suited to provide intu¬ 
itive semantics for dynamic policies. We focus in particular on the attacker-parametric 
model from Askarov and Chong in 0AC12I . 

Suppose that the input state to a program is a. In the knowledge-based approach, 
an attacker’s knowledge of a is modelled as a knowledge set K, which may be any 
set of states such that a € K. Note that the larger the knowledge set, the less certain 

















is the attacker of the actual value of a, so smaller K means more precise knowledge. 
(Sometimes, as we see below, it can be more intuitive to focus on the complement K, 
which is the set of a-priori possible states which the attacker is able to exclude, since 
this set, which we will call the exclusion knowledge, grows as the attacker learns more). 

Now suppose that the currently active policy is =. The essential idea in any know- 
ledge-based semantics is to view the equivalence classes of = as placing upper bounds 
on the attacker’s knowledge. In the simplest setting, if the actual input state is a and the 
attacker’s knowledge set is K, we require: 

K D {cr' \ a' = a} 

Or, in terms of what the attacker is able to exclude: 

KC{p\p^a} (1) 

How then do we determine the attacker’s knowledge? Suppose an attacker knows 
the program c and observes channel a. Ignoring covert channels (timing, power, etc) 
an obvious approach is to say that the attacker’s knowledge is simply a function of the 
trace t observed so far: 

Ht) = {P\{c,p)-^a} ( 2 ) 

We dehne the exclusion knowledge as the complement of this: ek{t) = k{t). Note 
that, as a program executes and more outputs are observed, the attacker’s exclusion 
knowledge can only increase; if {c,a)-k^^ then ek{t) C ek{t ■ v), since, if p can 
already be excluded by observation of t (because c cannot produce t when started in 
p), then it will still be excluded when t ■ v is observed (if c cannot produce t it cannot 
produce any extension of t either). 

But this simple model is problematic for dynamic policies. Suppose that the policies 
in effect when t and f • u are observed are, respectively =i and = 2 . Then it seems that 
we must require both ek{t) <Z {p \ p a} and ek{t ■ v) Q {p \ p ^2 o'}. As observed 
above, it will always be the case that ek{t) C ek{t ■ v), so we are forced to require 
ek{t) ^ {p \ p ^2 O'}. In other words, the observations that we can permit at any given 
moment are constrained not only by the policy currently in effect but also by all policies 
which will be in effect in the future. This makes it impossible to have dynamic policies 
which revoke previously permitted flows (or, at least, pointless; since all revocations 
would apply retrospectively, the earlier “permissions” could never be exercised). 

Askarov and Chong’s solution has two key components, outlined in the following 
two sections. 

3.1 Change in Knowledge 

Firstly, recognising that policy changes should not apply retrospecively, we can relax 
O to constrain only how an attacker’s knowledge should be allowed to increase, rather 
than its absolute value. The increase in attacker knowledge going from f to f • u is given 
by the set difference ek{t • v) — ek{t). So, instead of ([B. we require: 

ek{t ■ v) — ek{t) C {p | p ^ cr} (3) 

where = is the policy in effect immediately before the output v. (Some minor set- 
theoretic rearrangement gives the equivalent 

k{t • v) 3 k{t) n {cr' I cr' = ct} 
which is the form of the original presentation in OAC 121 .1 





3.2 Forgetful attackers 

Focussing on change in knowledge addresses the problem of retrospective revocation 
but it creates a new issue. Consider the following example. 

Example 2. The program in Figure |2] produces the same output many times, but only 
the first output is permitted by the policy. Assume that the value of x is 5. Before the 
first output, the knowledge set of an observer on channel a contains every possible 
store. After the first output the observer’s knowledge set is reduced to include only 
those stores cr where ct(x) = 5. This is allowed by the policy at that point. 

By the time the second output occurs, the policy prohibits any further flow from x. 
However, since the attacker’s knowledge set already includes complete knowledge of 
X, the second output does not actually change the attacker’s knowledge at all, so Q is 
satisfied (since k{t ■ v) = k{t)). Thus a policy semantics based on Q would accept this 
program even though it continues to leak the value of x long after the flow has been 
revoked. 


Askarov and Chong address this by revisiting the as¬ 
sumption that an attacker’s knowledge is necessarily deter¬ 
mined by the simple function of traces (|2]l above. Consider 
an attacker which/orgefs the value of the first output in ex¬ 
ample |2] For this attacker, the second output would come as 
a revalation, revealing the value of x all over again, in vi¬ 
olation of the policy. Askarov and Chong thus arrive at the 
intriguing observation that security against a more powerful 
attacker, one who remembers everything that happens, does not imply security against 
a less resourceful attacker, who might forget parts of the observations made. 

Forgetful attackers are modelled as deterministic automata. 


X — >■ a; 


out X 

on a; 

X -A a; 


while 

{true) 

out 

X on a 


Fig. 2 


Definition 5 (Forgetful Attacker o § III.A HACllIl ). A forgetful attacker is a tuple 
A =(S'a, sq: where Sa is the set of attacker states; sq C is the initial state; 

and (5a : Sa x Sa the (deterministic) transition function describing how the 

attacker’s state changes due to the values that the attacker observes. 


We write A{t) for the attacker’s state after observing trace t: 

A(e) = So 

A{t ■ v) = 6AiA(t),v) 

A forgetful attacker’s knowledge after trace t is defined as the set of all initial stores 
that produce a trace which would result in the same attacker state A{t): 

Definition 6 (Forgetful Attacker Knowledge o § III.A IIAC12I ). 

k{A, c, a, t) = {pi (c, p)^a S A(t') = A(t)} 


(Note that, in preparation for the formal definition of the security condition, program c 
and channel a now appear as explicit parameters.) 

The proposed security condition is still essentially as given by Q, but now relative 
to a specific choice of attacker. Stated in the notation and style of the current paper, the 
formal definition is as follows. 






Definition 7 (Knowledge-Based Security l> Def. 1 IIAC12I ). Command c is secure for 
policy D against an attacker A on channel a for initial store a if for all traces t and 
values V such that (c, cr)-^a(c', we have 

ek{A, c,a,t ■ v) — ek[A, c,a,t) C {p \ p ^ a} 
where = = Da{c, a, n). 


Having relativized security to the power of an attacker’s memory, it is natural to 
consider the strong notion of security that would be obtained by requiring Def. [T] to 
hold for all choices of A. However, as shown in IIAC12I . this exposes a problem with 
the model; there are attackers for which even well-behaved programs are insecure ac¬ 
cording to Def. |2l 


Example 3. Consider again the hrst example from the Introduction (Section fOT i. Here, 
for simplicity, we assume that the variable x is boolean, taking value 0 or 1. 


// X ^ a 
out X on a; 
// X-A a 
out 2 on a; 



It is intuitively clear that this program complies with the policy. However, as ob¬ 
served in MAC 1 21 , if we instantiate Def. |7] with the forgetful attacker displayed, the 
attacker’s knowledge increases with the second output when x = 0. 

After observing the value 0, the attacker’s state is A(0) = Qq. Since A(e) = Qq, the 
knowledge set still holds every store possible. After the second observation, only stores 
where x = 0 could have led to state q 2 , so the knowledge set shrinks (ie, the attacker’s 
knowledge increases) at a point where the policy does not allow it. 


This example poses a question which (so far as we are aware) remains unanswered: 
if we base a dynamic policy semantics on Def|2l for which set of attackers should we 
require it to hold? 

In the next section we dehne a progress-insensitive variant of Def]?] For this variant 
it seems that security against all attackers is a reasonable requirement and in Section|6] 
we show that progress-insensitive security against all attackers is indeed enforced by 
our type system. 

3.3 Progress Insensitive Security 

Since BVSI96L work on the formalisation and enforcement of information-flow poli¬ 
cies has generally distinguished between two flavours of security: termination-sensitive 
and termination-insensitive. Termination-sensitive properties guarantee that protected 
information is neither revealed by its influence on input-output behaviour nor by its 
influence on termination behaviour. Termination-insensitive properties allow the latter 
flows and thus provide weaker guarantees. For systems with incremental output (as 
opposed to batch-processing systems) it is more appropriate to distinguish between 
progress-sensitive and progress-insensitive security. Progress-insensitive security ig¬ 
nores progress-flows, where a flow is regarded as a progress-flow if the information that 
it reveals can be inferred solely by observing how many outputs the system produces. 













Two examples of programs with progress-flows are as follows: 

Example 4. Programs containing progress-flows: 

// Program A // Program B 

out 1 on a; out 1 on a; 

while (x == 8) skip; if (x != 8) out 2 on a; 

out 2 on a; 

Let a and p differ only on the value of x: (t(x) = 4 and p(x) = 8. Note that, if started in 
a, both programs produce a trace of length 2 (namely, the trace 1 ■ 2) whereas, if started 
in p, the maximum trace length is 1. Thus, for both programs, observing just the length 
of the trace produced can reveal information about x. Note that, since termination is not 
an observable event in the semantics, A and B are actually observably equivalent; we 
give the two variants to emphasise that progress-flows may occur even in the absence 
of loops. 

In practice, most enforcement mechanisms only enforce progress-insensitive secu¬ 
rity. This is a pragmatic choice since (a) it is hard to enforce progress-sensitive security 
without being overly restrictive (typically, all programs which loop on protected data 
will be rejected), and (b) programs which leak solely via progress-flows, leak slowly 
IIAHSS08I . 

Recall that Knowledge-Based Security (Def. |7]i places a bound on the increase in 
an attacker’s knowledge which is allowed to arise from observation of the next output 
event. Askarov and Chong show how this can be weakened in a natural way to pro¬ 
vide a progress-insensitive property, by artificially strengthening the supposed previous 
knowledge to already include progress knowledge. Their definition of progress knowl¬ 
edge is as follows: 

Definition 8 (AC Progress Knowledge [> § III.A IIAC12II ). 

A:+(A, c, a, t) = {p\ (c, p)-^^a A A{t') = A(t)} 

Substituting this (actually, its complement) in the “previous knowledge” position in 
Def.|2]provides Askarov and Chong’s notion of progress-insensitive security: 

Definition 9 (AC Progress-Insensitive (ACPI) Security |> Def. 2 IIACI2I ). Command 
c is AC Progress-Insensitive secure for policy D against an attacker A on channel a for 
initial store a if for all traces t and values v such that (c, trc have 

ek{A, c,a,t ■ v) — ek'^{A, c,a,t)C{p\p^ a} 
where = = Da{c, a, n). 

Now consider again programs A and B above. These are examples of programs 
where the only flows are progress-flows. In general, we say that a program is quasi¬ 
constant if there is some fixed (possibly infinite) trace t such that every trace produced 
by the program is a prefix of t, regardless of the choice of initial store. Thus, for a 
quasi-constant program, the only possible observable variation in observed behaviour 
is trace length, so all flows are progress-flows. Since PI security is intended explicitly 
to allow progress-flows, we should expect all quasi-constant programs to satisfy PI 
security, regardless of the choice of policy and for all possible attackers. But, for Def.|9l 
this fails to hold, as shown by the following counterexample. 









Example 5. Consider the program and attacker below. The attacker is a very simple 
bounded-memory attacker which remembers just the last output seen and nothing else 
(not even whether it has seen any previous outputs). 

// X 74 a 
out 1 on a; 
out 1 on a; 
while (x) skip; 
out 1 on a; 
out 2 on a; 

Clearly, the program is quasi-constant. However, it is not ACPI secure for the given 
attacker. To see this, suppose that x = 0 and consider the trace t = 1 ■ 1 ■ 1. The attacker 
has no knowledge at this point (k{t) is the set of all stores) since it does not know 
whether it has seen one, two or three I’s. It is easily verified that is also the set 

of all stores for this attacker (intuitively, giving this attacker progress knowledge in the 
form k^ doesn’t help it, since it still does not know which side of the loop has been 
reached). But k{t ■ 2) is not the set of all stores, since in state 52 the attacker is able to 
exclude all stores for which x = 1, thus ACPI security is violated. 

What has gone wrong here? The attacker itself seems reasonable. We argue that the real 
problem lies in the definition of k^{A, c, a, t). As defined, this is the knowledge that A 
would have in state A{t) if given just the additional information that c can produce at 
least one more output. But this takes no account of any previous progress knowledge 
which might have been forgotten by A. (Indeed, the above attacker forgets nearly all 
such previous progress knowledge.) As a consequence, the resulting definition of PI 
security mistakenly treats some increases in knowledge as significant, even though they 
arise purely because the attacker has forgotten previously available progress knowledge. 

Our solution will be to re-define progress knowledge to include what the attacker 
would know if it had been keeping count. To this end, for any attacker A = {S, sq, S) 
we define a counting variant = (5“, Sq , S‘^), such that S‘^ C S x N, Sq = (sq, 0) 
and (5“((s, n),v) = (6(s, w), n-f 1). In general, will be at least as strong an attacker 
as A: 

Lemma 2. For all A, c, a, t: 

1. k{A^, c, a, f) C k{A, c, a, t) 

2. ek{A, c, a, t) C ek{A^, c, a, t) 

Proof. It is is easily seen that A‘^{t) = {q,n) A{t) = q. Thus 

A{t') = A{t), which establishes part 1. Part 2 is just the contrapositive of part 1. 

Our alternative definition of progress knowledge is then; 

Definition 10 (Full Progress Knowledge). 

k*{A, c, a, t) = {p\ (c, p)-^^a A A‘^{t') = A^(t)} 

Our corresponding PI security property is: 







Definition 11 (Progress-Insensitive (PI) Security). Command c is progress-insensitive 
secure for policy D against an attacker A on channel a for initial store a if for all traces 
t and values v such that (c, cr) -^^{c'we have 

ek{A, c,a,t ■ v) — ek"^{A, c, a, t) C {p | p ^ a} 
where = = Da{c, a, n). 

This definition behaves as expected for quasi-constant programs: 

Lemma 3. Let c be a quasi-constant program. Then c is PI secure for all policies D 
against all attackers A on all channels afar all initial stores a. 

Proof It suffices to note that, from the definitions, if f • u is a possible trace for c and c is 
quasi-constant, then kA"{A^ c, a, t) = k{A^, c,a,t‘ v)- The result follows by Lemma|2l 

As a final remark in this section, we note that there is a class of attackers for which 
ACPI and PI security coincide. Say that A is counting if it always remembers at least 
how many outputs it has observed. Formally: 

Definition 12 (Counting Attacker). A is counting if A{t) = A{t') => |t| = |f'|. 

Now say that attackers A and A! are isomorphic (written A = A') if A{ti) = A{t 2 ) 
A'{ti) = A'( 12 ) and note that none of the attacker-parametric security conditions dis¬ 
tinguish between isomorphic attackers (in particular, knowledge sets are always equal 
for isomorphic attackers). It is easily verified that A = A‘^ for all counting attackers. It 
is then immediate from the definitions that ACPI security and PI security coincide for 
counting attackers. 

4 Progress-Insensitive Security as a Two-Run Property 

Our aim in this section is to derive a security property which guarantees (in fact, is 
equivalent to) PI security for all attackers, and in a form which facilitates the soundness 
proof of our type system. For this we seek a property in “two run” form. 

First we reduce the problem by establishing that it suffices to consider just the count¬ 
ing attackers. 

Lemma 4. Let cbe a command. Then, for any given policy, channel and initial store, c 
is PI secure against all attackers iff c is PI secure against all counting attackers. 

Proof. Left to right is immediate. Right to left, it suffices to show that 

ek{A, c,a,t ■ v) — ek'^{A, c, a, f) C ek{A^a,t ■ v) — ek'^{A^ a, f) 

Since A^ = we have ekI^{A^ ,c,a,t) = ek'^{A,c,a,t)- It remains to show 

that ek{A, c,a,t ■ v) C ek{A‘^,c, a, t ■ v), which holds by Lemma|2] 

Our approach is now essentially to unwind Def. [TT] Our starting point for the un¬ 
winding is: 

ek(A, c,a,t ■ v) — ek'^{A, c,a,t) Q {p \ p ^ a} 

where = is the policy in effect at the moment the output v is produced. Simple set- 
theoretic rearrangement gives the equivalent: 

{o' I cr' = cr} n kI^{A, c, a, t) C k{A, c,a,t- v) 


Expanding the definitions, we arrive at: 

p = aA{c,p)-^^^a,AA‘^{t') = A^{t) =A 3s.{c, p)-^^ A A{s) = A{t ■ v) 

By the above lemma, we can assume without loss of generality that A is counting, so 
we can replace = A“(t) by A{t') = A{t) on the Ihs. Since A is counting, we 

know that |t| = \t'\ and |s| = \t ■ v\, hence |s| = \t' ■ v'\. Now, since c is deterministic 
and both s and t' ■ v' start from the same p, it follows that s = t' ■ v'. Thus we can 
simplify the unwinding to: 

p = a A {c, p) * A A{t') = A{t) A{t' ■ v') = A{t ■ v) 

Now, suppose that this holds for A and that v' ^ v. Let q be the attacker state A{t') = 
A{t) and let r be the attacker state A{t' ■ v') = A{t ■ v). Since |f| ^ \t ■ v\ and A is 
counting, we know that q ^ r. Then we can construct an attacker A! from A which 
leaves q intact but splits r into two distinct states and . But then security will fail 
to hold for A', since A'(f' ■ v') = ^ r^r = A'{t ■ v). So, since we require security 

to hold for all A, we may strengthen the rhs to A{t' ■ v') = A{t ■ v) A v = v'. Then, 
given A{t') = A{t), since A is a deterministic automaton, it follows that u = u' => 
A{t' ■ v') = A{t ■ v), hence the rhs simplifies to just v = v' and the unwinding reduces 
to: 

p = a A {c, p) * A Ait') = A{t) ^ v' = v 

Finally, since A now only occurs on the Ihs, we see that there is a distinguished counting 
attacker for which the unwinding is harder to satisfy than all others, namely the attacker 
A^, for which A^it') = A^{t) iff \t'\ = |f|. Thus the property will hold for all A iff it 
holds for A^ and so we arrive at our two-run property: 

Definition 13 (Two-Run PI Security). Command c is two-run PI secure for policy D 
on channel a for initial store a if whenever {c, a)On)and p = a and 
(c, p) * > a and \t'\ = \t\, then v' = v, where = = Da(c, a, n). 

Theorem 1. Let c be a command. For any given policy, channel and initial store, c is 
PI secure against all attackers iff c is two-run PI secure. 

Proof. This follows from the unwinding of the PI security definition, as shown above. 

5 A Dependency Type System 

Within the literature on enforcement of information flow policies, some work is 
distinguished by the appearance of explicit dependency analyses. In the current paper 
we take as our starting point the flow-sensitive type systems of IIHSl 11HS061 . due to 
the relative simplicity of presentation. Other papers proposing similar analyses include 
IICHH02] . IIAB04I . IAR80I and IIBBL94I . Some of the similarities and differences be¬ 
tween these approaches are discussed in IIHS06I . 

The original work of 1IHS06I defines a family of type systems, parameterised by 
choice of a multi-level security lattice, and establishes the existence of principal typ¬ 
ings within this family. The later work of BHSl II defines a single system which pro¬ 
duces only principal types. In what follows we refer to the particular flow-sensitive type 
system defined in BHSl 111 system as FST. 
























Values V :;= n Expressions e ::= v \ x 

Commands c ::= skip | ci; C2 | x := e | if e ci C2 | while e c | out e on a @ p 


(skip;c,CT)_l^(c, cr) 


{ci,cr)^(c'i,CT') 


(j{e) = V 


(ci; C2, cr)_^(c'i; C2, o-') (x := e, cr)(skip, cr') 


cr(e) = w 

(out e on a @ p, rr) , (ski p, a') 


(while e c, ct) ^ (if e (c; while e c) skip, o) 


a{e) 7^ 0 cr(e) = 0 

(if e Cl C2, cr)_l7(ci, <j) (if e ci C 2 , cr)_i^(c2, cr) 
Fig. 4: Language and semantics. 


The typings derived by FST take the form of an environment F mapping each pro¬ 
gram variable x to a set F (x) which has a direct reading as (a conservative approxima¬ 
tion to) the set of dependencies for x. All other types derivable using the flow-sensitive 
type systems of I1HS06I can be recovered from the principal type derived by FST. Be¬ 
cause principal types are simply dependency sets, they are not specific to any particular 
security hierarchy or policy. This is the basis of the clean separation we are able to 
achieve between analysis and policy verification in what follows. 

Consider the simple program shown in Figure [3 The type in¬ 
ferred for this program is F, where T(x) = {}, F{j) = {y, z}, 

T(z) = {z}. From this typing we can verify, for example, any 
static policy using a security lattice in which level{z.) C level(j). 

FST is defined only for a simple language which does not in¬ 
clude output statements. This makes it unsuitable for direct appli¬ 
cation to verification of dynamic policies, so in the current paper 
we describe a straightforward extenion of FST to a language with output statements. 
We then show how the inferred types can be used to enforce policies such as those in 
flAC12ll and IIBvDS13l . which appear very different from the simple static, multi-level 
policies originally targeted. 

5.1 Language 

We instantiate the abstract computation model of Section 12.11 with a simple while- 
language with output channels, shown in Figure|4] We let x G P Var range over program 
variables, a € Chan range over channels (as before) and p G PPoint range over pro¬ 
gram points. Here non-silent output labels have the form (a, v,p), channel(a, v,p) = a, 
and value(a, w,p) = v. 

The language is similar to the one considered in MAC12L except for the absence of 
input channels. 

Outputs have to be annotated with a program point p to bridge between the depen¬ 
dency analysis and the policy analysis, described in Section|6l 

5.2 Generic typing 

Traditional type systems for information flow assume that all sensitive inputs to the 
system (here; program variables) are associated with a security level. Expressions in 


X : = z + 1; 
z : = X ; 
if (z > 0) 

Y := 1; 

X : = 0 ; 


Fig. 3 
















the command to be typed might combine information with different security levels. To 
ensure that all expression can be typed, the security levels are therefore required to form 
at least a join-semilattice, or in some cases a full lattice. The type system then ensures 
no information of a (combined) level li can be written to a program variable with level 
I 2 unless li C ( 2 - 

The system FST from Hunt and Sands BHSl II differs from these type systems in two 
ways. Firstly, it does not require intermediate assignments to respect the security lattice 
ordering. As an observer is assumed to only see the final state of the program, only the 
final value of a variable must not depend on any information which is forbidden by the 
lattice ordering. For example, suppose level{y) C level{z) C level{x) but level{x) % 
level{z) and consider the first two assignments in the example from Fig. [3 

x=z + l; z = x; 

A traditional type system would label this command as insecure because of the assign¬ 
ment z = X and the fact that level(x) % level{z), even though the value of z after 
this assignment does not depend on the initial value of x at all. FST however is flow- 
sensitive and allows the security label on x to vary through the code. 

Secondly, and more significantly, by using the powerset of program variables as 
security lattice, FST provides a principai typing from which all other possible typings 
can be inferred. 

Thus the typing by FST is generic: a command needs to be typed only once and can 
then be verified against any static information-flow policy. Since the ordering among 
labels is not relevant while deriving the typing, FST is also able to verify policies which 
are not presented in the shape of a security lattice, but any relational ‘may-flow’ predi¬ 
cate between security labels can be verified. 

5.3 Generic typing for dynamic policies 

We now present an extended version of FST which includes an additional typing rule 
for outputs. All the original typing rules of FST remain unchanged. 

Intuitively, an output on a channel is like the final assignment to a variable in the 
original FST, that is, its value can be observed. Since types are sets of dependencies, we 
could simply type an output channel as the union of all dependencies resulting from all 
output statements for that channel. This would be sound but unduly imprecise: the only 
flows permitted would be those permitted by the policy at aii times, in effect requiring 
us to conservatively approximate each dynamic policy by a static one. But we can do 
better than this. 

The flow-sensitivity of FST means that a type derivation infers types at intermediate 
program points which will, in general, be different from the top-level type inferred for 
the program. These intermediate types are not relevant for variables, since their inter¬ 
mediate values are not observable. But the outputs on channels at intermediate points 
are observable, and so intermediate channel types are relevant. Therefore, for each 
channel we record in F distinct dependency sets for each program point at which an 
output statement on that channel occurs. Of course, this is still a static approximation of 
runtime behaviour. While our simple examples of dynamic policies explicitly associate 
policy changes to program points, for real-world use more expressive dynamic policy 
languages may be needed. In Section lZ3 we formally define the semantics of a dynamic 




policy as an arbitrary function of a program’s execution history, which provides a high 
degree of generality. However, in order to apply a typing to the verification of such 
a policy, it is first necessary to conservatively approximate the flows permitted by the 
policy at each program point of interest (Definition [Tbll. 

Let X be the dependency set for the channel-a output statement at program point p. 
The meaning of X is as follows; 

Let (T be a store such that execution starting in a arrives at p, producing the 
Lth output on a. Let p be any store which agrees with a on all variables in X 
and also eventually produces an Lth output on a (not necessarily at the same 
program point). Then these two outputs will be equal. 

Two key aspects of our use of program points should be highlighted; 

1. While the intended semantics of X as outlined above does not require correspond¬ 
ing outputs on different runs to be produced at the same program point, the X that 
is inferred by the type system does guarantee this stronger property. Essentially 
this is because (in common with all similar analyses) the type system uses control- 
flow dependency as a conservative proxy for the semantic dependency property of 
interest. 

2. Our choice of program point to distinguish between different ouputs on the same 
channel is not arbitrary; it is essentially forced by the structure of the original type 
system. As noted, program point annotations simply allow us to record in the final 
typing exactly those intermediate dependency sets which are already inferred by 
the underlying flow-sensitive system. While it would be possible in principle to 
make even finer distinctions (for example, aiming for path-sensitivity rather than 
just flow-sensitivity) this would require fundamental changes to the type system. 

The resulting type system is shown in Figure |5] We now proceed informally to 
motivate its rules. Definitions and proofs of formal soundness are presented in Section|6l 
The type system derives judgements of the form l-{c}L, where F : Var 2 is 
an environment mapping variables to a set of dependencies. The variables we consider 
are Var = PVar U CPoint U {pc} U Chan with CPoint = Chan x PPoint. We 
consider the relevance of each kind of variable in turn. 

- As program variables PVar form the inputs to the command, these are the depen¬ 
dencies of interest in the typing of a command. For program variables themselves, 
P (x) are the dependencies for which a different intial value might result in a dif¬ 
ferent final value of x. 

- Pairs of channels and program points (a,p) € CPoint are denoted as Cp. The 
dependencies r{ap) are those program variables for which a difference in initial 
value might cause a difference in the value of any observation that can result from 
an output statement for channel a with annotation p. 

- Whenever the program counter pc G T(x) this indicates that this command poten¬ 
tially changes the value of program variable x. Similar, if pc G T(a) then c might 


^ This is progress-insensitive dependency (see Section 1^. A progress-sensitive version can be 
defined in a similar way. 



TS-Skip 

TS-Assign 


TS-Seq 


I- {skip} Fid 

h {x := e} Fid [x fv(e) U {pc}] 
h {ci}ri h {c2}F2 
1 “ {ci ; C2} 12; Fi 


TS-IfElse 

h {ci}Fi h 7 }' = Fi-Fid[pc {pc} U^(e)] i = l ,2 
\- {if e Cl C2} {F[ U -r2)[pc {pc}] 

TS-While 

l~ {c}Fc _ Ff = {Fc■,F^d[pc ^ {pc} U/t;(e)])* 

h {while e c} Ff [pc 1—{pc}] 

TS-Output 

h {out e on a @ p}Fid[ap !->• fv(e) U {pc, a, a^}; a i->- {pc, a}] 


Fig. 5; Type System. 


produce an output on channel a and if pc £ T(op) then c might produce an output 
on a caused by a statement annotated with p. We use the program counter to catch 
implicit flows that may manifest in these ways. 

- We use Chan to capture the latent flows described in example program B in the 
introduction. The dependencies r{a) are those program variables for which a dif¬ 
ference in initial value might result in a different number of outputs produced on 
channel a by this command. This approach to address latent flows was first intro¬ 
duced in 0AC12I as channel countext bounds. 

We first explain the notation used in the unchanged rules from FST before turning our 
attention to the new TS-Output rule. All concepts have been previously introduced 

in llHSm . 

The function fv{e) returns the free variables in expression e. The identity environ¬ 
ment Fid maps each variable to the singleton set of itself, that is Fidix) ={x} for all 
X £ Var. Sequential composition of environments is defined as: 

r2-,r,{x)= y A(2/) 

y&r2{x} 

Intuitively, A; A is as A but substituting the dependency relations already established 
in A-We overload the union operator for environments: (AUA)(a:) = A(a:)UA(a:)- 
We write F* for the fixed-point of T, used in TS-While: 

r* =[j where T° = Ad and = r^-,r 

n>0 

It is only in the typing TS-Output of the output command that the additional chan¬ 
nel and program point dependencies are mentioned; this underlines our statement that 
extending FST to target dynamic policies is straightforward. 









We explain the changes to Fid in TS-Output in turn. For ap, clearly the value of 
the output and thus the observation is affected by the program variables occuring in 
the expression e. We also include the program counter pc to catch implicit flows; if we 
have a command of the form if e (out 1 on a @ p) (out 2 on a @ q) the value of the 
observation caused by output ap is affected by the branching decision, which is caught 
in TS-IfElse. 

We include the channel context bounds a for the channel on which this output oc¬ 
curs to capture the latent flows of earlier conditional outputs, as demonstrated in the 
introduction. Observe that by the definition of sequential composition of environments, 
we only add those dependencies for conditional outputs that happened before this out¬ 
put. That is, not the ones that follow this output, since it cannot leak information about 
the absence of future observations. 

Finally, we include the dependencies of output point Up itself. By doing so the de¬ 
pendency set of Op becomes cumulative: with every sequential composition (including 
those used in F*) the dependency set of Op only grows, as opposed to the dependencies 
of program variables. This makes us sum the dependencies of all outputs on channel a 
annotated with the same program point, as we argued earlier. 

The mapping for channel context bounds a is motivated in a similar manner. The 
pc is included since the variables affecting whether this output occurs on channel a 
are the same as those that affect whether this statement is reached. Note that we are 
over-approximating here, as the type system adds the dependencies of e in 
if e (out 1 on a @ pi) (out 2 on a @ P 2 ) 
to context bounds a, even though the number of outputs is always one. 

Like for Op, we make a depend on itself, thus accumulating all the dependencies 
that affect the number of outputs on channel a. 

As the TS-Output rule does not introduce more complex operations than already 
present, the type system has the same complexity as FST. That is, the type system can 
be used to construct a generic type in 0{nv^) where n is the size of the program and v 
the number of variables in Var. 

6 Semantic Soundness and Policy Compliance 

We present a soundness condition for the type system, and show that the type system 
is sound. We then describe how the generic typings that the type system derives can be 
used to check compliance with a dynamic policy that is approximated per program 
point. We begin by showing how an equivalence relation on stores can be created from 
a typing: 

Definition 14. We write =r{x)for the equivalence relation corresponding to the typing 
F of variable x € Var, defined as a =r{x) P iff'^ij) = Piv) for all y G F(x). 

As we are using F{ap) as the approximation of dependencies for an observation, the 
soundness of the PI type system is similar to the PI security for dynamic policies, except 
that we take the equivalence relation as defined by F{ap) rather than the policy D. 

Definition 15 (PI Type System Soundness). We say that the typing F{c}/^ is sound 
ijffor all a,p, if {c,a)-^*{ccr,cr') > and {c, p)VL^*{cp, p')^^ and \t\ = \t'\ 

thena=r(ap) p^v = v'. 



Theorem 2. All typings derived by the type system are sound. 

The proof for Theorem|2]can be found in AppendixlAl 

To link the typing and the actual dynamic policy, we rely on an analysis that is able 
to approximate the dynamic policy per program point. A sound approximation should 
return a policy that is at least as restrictive as the actual policy for any observation on 
that program point. 

Definition 16 (Dynamic Policy Approximation). A dynamic policy approximation 
A : CPoint —>■ 2^^^ is a mapping from channel and program point pairs to an 
equivalence relation on stores. The approximation A on command c, written c : A, 

is sound for dynamic policy D iff, for all a if (c, a) _ y^{c', cr') Aw,p) , then A{ap) is 

coarser than D{c, a, n). 

We now arrive at the main theorem in this section. Given a typing we can 

now easily verify for command c its compliance with any soundly approximated dy¬ 
namic policy, by simply checking that the typing’s policy is at least as restrictive as the 
approximated dynamic policy for every program point. 

Theorem 3 (PI Dynamic Policy Compliance). Let c. Abe a sound approximation of 
dynamic policy D. If\-{c\r and =r{ap) is coarser than A{ap) for all program points 
Gp, then c is two-run PI secure for D on all channels and for all initial stores. 

Proof. Given a store a such that {c, a) Al^2{ccj, cr') and a store p such that 

(c, p)-^a(cp, ^nd \t\ = \f \ and aDa{c, a, n)p, we need to show that v = v'. 

Since c: A is a sound approximation of D, we have that aA(ap)p and as =r{ap) is 
coarser than A{ap) we also have a =r{ap) P- Which by Theorem|2]gives us that v = v'. 

Corollary 1. If the conditions of Theorem^are met, then c is PI secure for D for all 
attackers. This is immediate by Theorem\I] 

7 Related Work 

In this section we consider the related work on security for dynamic policies and on 
generic enforcement mechanisms for information-flow control. We already discuss the 
knowledge-based definitions by Askarov and Chong 0AC12I in detail in Section |3] 

The generality of expressing dynamic policies per execution point can be identified 
already in the early work by Goguen and Meseguer 0GM82I . They introduce the no¬ 
tion of conditional noninterference as a noninterference relation that should hold per 
step in the system, provided that some condition on the execution history holds. Condi¬ 
tional noninterference has been recently revisited by Zhang flZhal2l who uses unwind¬ 
ing relations to present a collection of properties that can be verified by existing proof 
assistants. 

Broberg and Sands IIBS09I developed another knowledge-based definition of secu¬ 
rity for dynamic policies which only dealt with the attacker with perfect recall. The 
approach was specialised to the specific dynamic policy mechanism Paralocks BBS 101 
which uses part of the program state to vary the ordering between security labels. 

Balliu et al. BBDLGl II introduce a temporal epistemic logic to express information 
flow policies. Like our dynamic policies, the epistemic formulas are to be satisfied per 
















execution point, suggesting that we are able express a similar set of dynamic policies. 
Dynamic policies can be individually checked by the ENCoVer tool IIBDLG12II . 

The way in which we define dynamic policies matches exactly the set of syn¬ 
chronous dyanmic policies; those policies that deterministically determine the active 
policy based on an execution point. Conversely, an asynchronously changing policy 
cannot be deterministically determined from an execution point, but is influenced by an 
environment external to the running program. 

There is relatively little work on the enforcement of asynchronous dynamic poli¬ 
cies. Swamy et al. IISHTZ06II present the language Rx where policies are define in a 
role-based fashion, where membership and delegation of roles can change dynamically. 
Hicks et al. I1HTHZ05II present an extension to the DLM model, allowing the acts-for 
hierarchy among principals to change while the prorgam is running. 

Both approaches however need a mechanism to synchronise the policy changes with 
the program in order to enforce information-flow properties. Rx uses transactions which 
can rollback when a change in policy violates some of the flows in it, whereas the 
work by Hick et al. inserts automatically derived coercions that force run-time checks 
whenever the policy changes. 

One of the beneficial characteristics of our enforcement approach is that commands 
need to be analysed only once to be verified against multiple information-flow policies. 
This generality can also be found in the work by Stefan et al. BSRMMl 111 presenting 
LIO, a Haskell library for inforamtion-flow enforcement which is also parametric in 
the security policy. The main differences between our approach and theirs is that LlO’s 
enforcement is dynamic rather than static, while the enforced policies are static rather 
than dynamic. 

8 Conclusions 

We extended the flow-sensitive type system from IIHS06I to provide for each output 
channel individual dependency sets per point in the program and demonstrated that this 
is sufficient to support dynamic information flow policies. We proved the type system 
sound with respect to a straightforward two-run property which we showed sufficient 
to imply knowledge-based security conditions. 

As our approach allows for the core of the analysis to be performed even before the 
policy is known, this enables us to reuse the results of the dependency analysis across 
the verification of multiple types of policies. An interesting direction for future research 
could be on the possibility to use the dependency analyses performed by advanced 
slicing tools such as JOANA MJOAII and Indus Hindi . 
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A Type System Soundness 

We need a collection of lemmas on the type system, which we prove correct in 
appendix iBl 

Lemma 5 (Preserving Dependencies). The dependencies of program points only in¬ 
crease with sequential composition. That is, if\-{ci}ri and l“{ci; C 2 \r then /i(ap) C 
r{ap) for all Up. 

Lemma 6 (Non-Branching Reduction). For all configurations c and stores a, p such 
that l-{c}r' with (c, cr)_2_^(c', cr') and {c, p) JL^{c', p'), i.e. to the same command 
c', where a, is either an output or e. Then <T=r{ap)P implies that \-{c'}r' and 
0-' =r'(ap) P'- 

Lemma 7 (Branching Reduction). For all configurations c and stores a, psuch that 
l-{c}/^ with (c, cr)_l_^(c^, cr') and (c, p)jL^{c'p, p'), where c'p. For all Op such that 
(cj^, a') > *, it holds that if a =r{ap) P then either: 

- There exists a joining command Cj with ti A t, such that {c'^, a') > a{cj, of) and 
{c'p, p')-^a{cj, Pj) with |fi| = |f'i| and 'r{cj}rj with ay =rj{ap) Pj- le. both ex¬ 
ecutions join again at equal command Cj after an equal number of outputs with 
equivalent dependencies for Op, or 

- For all t' such that (c, |f| > \t'\. 

We restate the semantic soundness property for the progress-insensitive type sytem: 

For all n > 0, for all commands c with typing h{c}I^, we 
have for all stores a, p, if (c, a}-^g(cer, tr') > and 

{c,p)-^a{cp,p')-^a and \t\ = \t'\ then a=r{a^)p ^ 

V = v'. 

We show this by complete (strong) induction on n. 

(n = 0) When c produces an output in a single step for some store, it does so for any 
store and at the same program point (Fig. 0. We need to show 

(c, a) > A g =r(ap) P A(c, p) ^ v = v' 

By induction on the step taken from (c, a). Due to the output, there are only two cases 
that do not lead to immediate contradiction; 

- out e on a @ p - By TS-Output, fv{e) C r(l,p). Therefore, cr(e) = p{e) and 
thus V = v'. 

- ci;c 2 - By Lemmaj^ ri{l,p) C r{l,p) for h{ci}Ti- Therefore a—ri(a^) p and 
the property follows by induction on (ci, a). 






c;,p') 


(n + 1 > 0) We have (c, a)-^„(c;, o-')-4g(c'^ a") > and (c,p)^„(. 

with the induction hypothesis (IDi for evaluations of length < n. 
Here a could be either silent or an output. We only consider the case where a is silent; 
for the case where a is an output the proof is similar except in the induction step we 
have that traces produced by tr' and p' are both 1 shorter in length. 

When c produces no output in a single step for some store, it does so for any store 
(Fig.gJ. We case split on c'^ = Cp- 

= Cp By Lemma|B] \-{c'^}r' and a' =r'{ap) p'- The case follows by induction on 


c'^ ^ dp Since (c, p) produces a trace longer than |f|, by Lemma [7] there exists a 
^ f such that (cj^, a") > and there is 

such that (cp, with |f'^| = |fi | and l-{cj}Lj 

with Uj =r^(a^) Pj. 

Since |f| = \t'\ and |fi| = \t[\ we have \t 2 \ = Then the case follows 
by induction on some n 2 < n. 


B Proofs of auxiliary lemmas 

We proof our auxiliary lemmas as part of a series of necessary properties of the type 
sytem. In this section, the Lemmas |5]|6] and |7]can be found with proof as Lemmas [TSl 
[Thl andfTTlrespectivelv. 


Lemma 8. For all l-{c}L, we have T(pc) ={pc}. 


Proof. By induction on the typing derivation. This property holds clearly for TS-Skip, 
TS-Assign and TS-Output as T(pc) = Lid(pc) ={pc}. It is also clear for TS-IfElse 
and TS-While as they explicitly reset the dependencies of pc to {pc}. For TS-Seq, 
by induction we have / 2 (pc) ={pc} thus 12 ; r'i(pc) = Li(pc), which by induction is 
(pc). 

Lemma 9. For all hlclL, if pc ^ r{x) then r{x) = Fidi^x) = {x},for all variables, 
channels and program points x. 

Proof By induction on the derivation of hjcjL: 


- Case: TS-Assign 

r is different from Fid only for variable x. For x, pc € L(x) so the property holds 
trivially. 

- Case: TS-Output 

F is different from Fid only for channel a and program point Op. For them, pc G 
F{a) and pc G F{ap) so the property holds trivially. 

- Case: TS-Seq 

By Lemma|8l Li(pc) = / 2 (pc) = {pcj.Thuspc G 12 ( 0 ;) implies pc G F 2 \Fi{x). 
Reversely, pc ^ F 2 \Fi{x) implies pc ^ 12 ( 3 :). By induction we then have 12 ( 0 ;) = 
{a:}. Thus F 2 \Fi{x) = Fi(x) and we have pc ^ Fi{x). Therefore by induction 
Fi[x) = F^dix) which gives F 2 ]Fi{x) = {a:}. 





- Case: TS-IfElse 

The composition with Fidlpc M-{pc} U/?;(e)] only adds dependencies and does not 
remove the dependency on pc. So pc £ Fi^x) implies pc £ F'{x). F is the union 
of both typing, so pc £ Fl{x) implies pc £ F{x). Reversely, pc ^ F{x) implies 
pc ^ Fi{x). By induction, Fi{x) = {x}, thus F'{x) = {x}, thus F{x) = {a:}. 

- Case: TS-While 

The composition with Fid[pc n-{pc} Ufv{e)] only adds dependencies and does not 
remove the dependency on pc. So pc £ Fc{x) implies pc £ F^, Fid[pc i->{pc} U 
fv{e)]{x). The reflexive transitive closure operation takes the union over all C", so 
pc £ Fc (x) implies pc £ Ff{x). Reversely, pc ^ Ff{x) implies pc ^ Fc{x). By 
induction, Fc{x) = {x}, hence neither the composition with Fid[pc n-{pc} U/w(e)] 
nor the closure operation modifies the dependencies of x, and Ff{x) ={a:}. 

Lemma 10. If pc ^ F{x) with l-{c}C and (c, rr) ° (rf rr'), then pc ^ F'{x) with 
\-{c'}F' ,for all x in variables, channels and program points. 

Proof. By induction on the structure of c: 

- Case: skip 

Holds trivially as there is no progress. 

- Case: ci; C 2 

F = F 2 \ Fi with l-{ci}ri and l-{c 2 }/ 2 . If pc ^ F{x) then by Lemma[8]we have 
pc ^ F 2 {x). By Lemma |9] we have F 2 \Fi(x) = {a:}; F 2 {x) = {a:} and thus 
pc ^ Fi{x). The case follows by induction on ci. 

- Case: x := e 

Becomes skip after evaluation. For all variables y other than x, pc ^ T(y) and 
also pc ^ F'{y) as F'{j) = ^idiy). Similar for program points and channels 

- Case: out e on a @ p 

F{x) = Fid{x) for all variables, channels and program points other than a and Op 
so the property holds. For a and Op, we have pc £ F{a) and pc £ F{ap) so holds 
trivially. 

- Case: if e ci C 2 

pc ^ F{x) implies pc ^ Fi{x) and pc ^ / 2 (a;); see proof of Lemma|9] Thus 
property holds for both cr(e) ^ 0 {F' = Fi) and cr(e) = 0 {F' = F 2 ). 

- Case: while e Ci 

If pc ^ T(x)thenpc ^ Fi{x) with hlcilTi; see proof of Lemma|9] Thus ^(a:) = 
F{x) = {x} by Lemma|9]and F ; Fi{x) = {x}. By inspecting the typing of c' it 
follows that F'{x) = {F- Fi] Fid[pc {pc} U fv{e)] U Fid){x) = {x}, thus 
pc (f F'{x). 

Lemma 11. Let h{while e c}F and h{if e (c; while e c) (skip)}T'. Then F'(x) C 
F (x) for all x in variables, channels and program points. 

Proof. Here, F = //[pc M- {pc}], with / / = {Fc', Fid[pc i-y {pc} U/?;(e)])*. We refer 
to the individual typings collected by the union in Ff with C". 

Let l-{c}/},. We need to show that Ffx) C F{x) which by substituting F' is: 

{{F ; Fc); F^ [pc {pc} U fv{e)] 

U F^d;F^d[pc {pc} U/(;(e)])(x) C F{x) 


Observing that a; 7 ^pc and thatC I^(x) since= (r'c;-^i(i[pc i—7 

{pc} U/y(e)])*, this becomes: 

{{r ; Tc); r,d. [pc (pc) U fv{e)]) (x) C r(x) 

If y € this means there exists a F" such that y G r'^{x). Thus, (r'c;Tjd[pc >-7 

(pcj U/-i;(e)])(y) C r"+i(x) C r{x). As r^y) C (r^; r,d[pc jpcj U/t;(e)]) (y) 
we have that for all y G F(x), T'c(t/) C r(x). Thus T; rc(x) C r(x), so the relation 
we need to show is implied by 

(r;Tjd[pc iH- {pc} U/?;(e)])(x) C r(x) 

(If we want to be more precise, it holds that (F ; FcUFid)(x) = F(x}, so this relation is 
in fact equivalent to the one we started out with.) If pc G F(x), then there exists a T" 
such that pc G F'^(x). As by LemmaO T’c(pc) = {pc}, it follows that IT; Fid[pc H> 
{pc} U/t;(e)](pc) = {pc} U fv{e). Thus since 1""+^ = F'^-{Fc, Fid[pc i-)- {pc} U 
/w(e)] (pc)), it follows that {pc}U/y(e) C 7^"+^ (a;) and therefore {pc}U/u(e) C F{x). 
So the relation simplifies to F{x) C F{x) which holds trivially. 

Lemma 12 (Program Counter). The typing |-{c}T guarantees that: 

7. If pc ^ F{x) and (c, a) _^*(skip, a') then (t(x) = cr'(x). 

2. If pc (f F{a) and (c, cr)-I^* then t = e. 

3. If pc ^ F{ap) and (c, cr)-^* then ap ^ t. 

Proof Property[T]by induction on n in (c, cr)(skip, cr'). If n = 0 the property holds 
trivially as cr = a'. We thus have: (c. rr) ^"(skip.rr") and by induction 

if pc 0 T'(x) with |-{c'}7^', then (t'(x) = cr"(x). By Lemma fTOl pc ^ T(x) then 
pc ^ F'{y.) so we can use the induction hypothesis. 

Similar for properties|2]and[3 

Lemma 13 (Variables). For all c, cr, p such that h{c}L with (c, cr)_^*(skip, a') and 
(c, p)_).*(skip, p'), then a =r{yi) p implies cr'(x) = p'(x). 

Proof By complete induction on n in (c, cr)_^rr (skip, tr'). If n = 0 the property holds 
trivially a = a', p = p', F = Fid and thus p(x) = ct(x). We then have (c, cr) « ^ 
(c', cr')_^n(skip, cr") and (c, p) P- > (c", p')_>*(skip, p”). By induction if a' =r'(x) p' 
with l-{c'}L' then cr"(x) = p"(x). 

By cases on the hrst evaluation step: 

- (skip;c,cr)_l^(c,CT). 

F = F'\Fid so cr =r(x) P implies cr =r'{x) P and as cr = cr' and p = p' the case 
follows by induction. 

- (ci; C 2 , cr) (c'l; C 2 , cr') with (ci, cr) (c}, cr'). 

F = 72; A - By dehnition of ; this means that cr =r{x) P implies that cr =ri(y) P for 
all y G A(x). Thus in the computations (ci; C 2 , cr)_j,*(skip; C 2 , cr')_^*(skip, cr") 
and (ci;c 2 ,p)_>* (skip;C 2 ,p')_>*(skip,p") we have by induction on ci that 
cr'(y) = p'(y). Therefore cr' =r’ 2 (x) p' and the case follows on the shorter execution 
trace produced by C 2 . 


- (x := e, CT)_i_^(skip, (t[x z;]) with cr(e) = v. 

For X, we have fv{e) C r{x). Therefore, cr=r(x) P implies that a{e) = p{e) and 
cr'(x) = a{e) = p{e) = p'{x). For all variables y other than x, the store is left un¬ 
changed and thus (T(y) = cr'(y) and therefore cr(y) = p(y) implies (T'(y) = p'(y). 

- (out e on a @ p, cr)(skip, a) with a{e) = v. 

As this step leaves the store unchanged, the property holds trivially. 

- (if e Cl C 2 , cr)_l^(ci, (t) with (T(e) 7 ^ 0. 

If pc 0 T(x) Lemma |9] gives that L(x) = {x}. Lemma [12] tells us that a{x) = 
cr"(x) and p(x) = p"{x) thus by (t(x) = p(x) we are done. Otherwise, pc G r{x) 
implies by TS-IfElse that fv(e) C L(x) which means that cr(e) = p(e) and the 
case follows by induction on the shorter execution trace of Ci. 

- (if e Cl C 2 , cr)_l.j.(c 2 , cr) with (T(e) = 0. 

Analogous to cr(e) ^ 0. 

- (while e c, (T)_l 7 (if e (c; while e c) (skip), a). 

By Lemma [TT] L'(x) C L(x) and as cr = cr' and p = p' the case follows by 
induction. 

Lemma 14 (Channel Context Bounds). The typing F{c}L guarantees that: 

1. 7/'(c, cr)-^*(skip, cr') and er=r(a)P (c, p)-^* has |f| > |f'|, and if also 
(c,p)-^*(skip,p') then \t\ = \ f\. 

2. If a r{ap) and (c, cr)-^* then Up ^ t. 

Proof For property |2| the reasoning is anologous to that for property [3] in Lemma fl^ 
The rest of the proof is for property]!] 

By complete induction on n in (c, cr)-^j(skip, a'). If n = 0 the property holds 
trivially. We then have (c, a) PL >(c', (skip, a”) and (c, p) i. >(c", p')-^a- 

By cases on the first reduction step; 

- (skip;c,cr)_l 7 (c,cr). 

r = r'; Fid so cr =r(a) P implies a=r'(a) P as a = a', p = p' and c' = c" 
the case follows by induction. 

- (ci;c 2 ,cr)_^(c'i;c 2 ,cr') with (ci,cr)_^(c'i,cr'). 

Let l-{ci}A- By property]^ of Lemma [Tsl A(a) Q r{a), thus <J=r{a) P implies 
cr =ri{a) P- As the command fully evaluates, so does ci: (ci, cr)-A^»^i(skip, cr") 
and therefore also (ci; C 2 ,o')-^^f^{c 2 , cr"). As ni < n, by induction we have that 
{ci,p)-^* with |f'i| < |fi| and if (ci, p)^*(skip, p") then |f'i| = |fi|. 

As r = A; A, for all x G A (a) we have (J=ri(yi) p, and by Lemma[T3]cr"(x) = 
p"(x) which means that cr" =r 2 (a) p" and the property follows by induction on the 
execution of length n — ni. 

- (x := e, cr)_A(skip, cr[x i—>■ uj) with cr(e) = v. 

As this configuration never produces any output, this property holds trivially. 

- (out e on a @ p, cr) (“■".p) ). (ski p, cr) with cr(e) = v. 

As this configuration produces only one output, always on the same channel, this 
property holds trivally. 




- (if e Cl C 2 , cr)_l^(ci, tr) with tT(e) 0. 

If pc ^ r{a) this means that c never produces an output on a by property |2] of 
LemmafT^and we are done. 

Otherwise, pc G r{a) and therefore/?;(e) C r{a) and p{e) = a{e) ^ 0. Thus 
also (c, p)-L^{ci,p). As A(a) Q r{a), this follows directly by induction. 

- (if e Cl C 2 , cr)-i->.(c 2 , cr) with (T(e) = 0. 

Analogous to when a{e) ^ 0. 

- (while e c, rr) > (i f e (c; while e c) skip, tr). 

By Lemma [TT] L'(a) C r{a) and as cr = cr' and p = p' the case follows by 
induction. 

Lemma 15 (Preserving Dependencies). The dependencies of program points and con¬ 
text bounds only increase with sequential composition: 

1 . If\-{ci}riand\-{ci;c2}rthenri{ap) C r(ap) for all Up. 

2 . If\-{ci\ri and Ljci; C2}T then A(a) C L(o) for all a. 

Proof For property [T] First, we establish that for all typings l-{c}L, Op G r{ap) 
by induction on the typing. This property clearly holds for TS-Skip, TS-Assign and 
TS-Output. For TS-Seq, by induction Op G Alop). Thus A(ap) L T(op). By in¬ 
duction we also have Op G A(ap) and thus Op G T(ap). For TS-IfElse, we have 
A(ap) C r{ap) and it follows by induction. For TS-While, we have Fc^ap) C r{ap) 
since A; A(i[pc i-G {pc} U /c(e)] is in the union that dehnes F and this case follows 
by induction as well. 

So if F{ci}A and F{c 2 }T 2 this means Fjci; C 2 }A; A- As Op G A(ap)’ 

A(ap) — ^i^p) which is what we had to show. 

Similar for property!!] 

Lemma 16 (Non-Branching Reduction). For all configurations c and stores a, p such 
that hlclL with Ic^ rr) (d. a') and (c-p) P) {rfp'), i.e. to the same command 
c', where a, is either an output or e. Then <J—r{ap)P implies that hjc'jL' and 
0-' =r'(ap) P'- 


Proof. By induction on the small step evalation. 

- (skip;c, tr) _A (c, <j) and (skip;c, p) _A (c, p) 

Typing gives us L = A; Ad and F' = A- As A; Ad = A we have that F = F', 
a— a' and p = p'; and a' = r'(ap) p' holds trivially. 

- (ci; C2, cr) (c'l; C2, cr') with (ci, cr) _ 2 Lj. (c'l, cr') and 

(ci;c2,p)^(c'i;c2,p') with (ci,p)^(c'i,p') 

By induction there exists a F[ such that |-{c}}A^ and cr' =r'{ap) p'■ ^ = A; A and 
A = A; A'- When CT =7-2.ri(ap) P then by dehnitionof ;, Vy G A(ap).cr =r^(y) p. 
By induction we also have that Vy G A(ap)-'^^ ~ri{7) P'■ Thus a' =r2-,r{{ap)) p'■ 

- (x := e, cr)_A(skip, cr[x i—>■ uj) with cr(e) = v and 
(x := e, p)_A(skip, p[x w]) with p(e) = w 
As F' = Fid, cr' =rii(ap) p' holds for any cr', p'. 


- (out e on a @ p, O') ^ (skip, a) with a{e) = v and 

(out e ona @p, p) ^ (skip, p) with p{e) = w 

Similar as for assignment. 

- (if e Cl C2, cr)_l_^(ci, (t) with a{e) ^ 0 and 
(if e Cl C2,p)-l^(ci,p) 

As cr' = cr and p' = pv^s need to show that A(ap) Q r{ap) which is clear from 
the typing rule. 

- (if c Cl C2, cr)_l_^(c2, cr) with cr(c) = 0 and 

(if C Cl C 2 ,p)-l^(c 2 ,p) 

As cr' = cr and p' = p we need to show that /2(cip) C ricLp) which is clear from 
the typing rule. 

- (while c c, cr)_t_!.(if c (c; whilecc) skip, cr) and 
(while c c, p)-!-^ (if c (c; while cc) skip, p) 

As cr' = cr and p' = p it follows from r'{ap) C r{ap) by LemmafTTl 

Lemma 17 (Branching Reduction). For all configurations c and stores cr, p such that 
h{c}/^ with (c, a)-L^{c'^, a') and (c, p)-L^{c'p, p'), where c'^ dp. For all Up such that 
{d^, cr') 1 (°'"’P 1 if f/raf f/cr p then either: 

- There exists a joining command cj with ti A t, such that (c(,, cr') — > a{cj, ofi) and 
{dp, p')-^*{cj, pj) with |fi| = and d{cj}rj with aj =rj{ap) Pj- le. both ex¬ 
ecutions join again at equal command Cj after an equal number of outputs with 
equivalent dependencies for Op, or 

- For all t' such that (c, p)-^*, |f| > \t'\. 

Proof By induction on the small step evalation (c, a)^L^{d^, cr'). There are only three 
evaluations that may result in a different command for different stores, the others hold 
trivially. 

- (if C Cl C2, cr)_l_j,(ci, cr) with cr(c) ^ 0 

• If pc e r{ap) then the typing rules give that cr(c) = p(c) and both executions 
take the same branch; hence d^ = dp so we contradict our assumption. 

• If pc ^ r{ap) then by Lemma fT^ (c, a) should not produce an output on Op, 
which contradicts our assumption. 

- (if C Cl C2, cr)_l_^(c2, cr) with cr(c) = 0 
Similar as for cr(c) f 0 

- (ci; C2, cr) (c'l; C2, cr') with (ci, cr) (c'l, a') 

• Cl produced {a,v,p), that is (ci,cr) By property [T] of Lemma [TSj 

A(ap) C r{ap), therefore a=r{ap) P implies cr=ri(ap) P and the case fol¬ 
lows by induction. 

• C2 produces {a,v,p). That is, ci evaluates completely {ci,a)d^*(^s'kip,aj) 

and thus (ci; C2, cr)^t->-*(c2, ctj) By Lemma[T 4 l property | 2 l as C2 

produces an output on Op, it must be that a G 12(0^). As F = /2; A with 
l-{ci}r'i, l-{c2}/2 and cr =_r(ap) P this means that cr =ri{a) P- By Lemma fT 4 l 
property [T] we get that for all t[ such that {ci, p)df^* has |fi| > \t[\ and 
if (ci, p)^J->'*(skip, pj) then |fi| = If ci diverges this means that the 







second case of Lemma [T 71 holds and we are done. Otherwise we also have that 
(ci, p) * (skip, pj) and thus (ci ',02, p) (c2 ,Pj). Again by L = r'2; A 
and (T p we have that Vx S r2{l,p).(7 =ri{x) P- By LemmafTslit follows 

that aj =r’2(ap) Pj, which is what we had the show (with Cj = C2). 


